MULTIsrfHOP PEraR-TO-PEER TELECOMMUNICATIONS METHOD IN A WIRELESS 
NE TWORK^RAD I O TERMINAL TELECOMMUNICATIONS METHOD, AND MEDIUM 
RECORDING A PROGRAM FOR CAUSING A PROCESSOR TO IMPLEMENT THE RADIO 

TERMINAL TELECOMMUNICATIONS METHOD 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

The present invention relates to a protocol for performing 
multi-hop peer-to-peer telecommunications in a wireless network, and 
a radio terminal telecommunications method, 

2 . Description of the Related Art 

The Internet Protocol (IP) is known as a data telecommunications 
protocol using a network. This protocol is widely used on the 
Internet . 

Recently, wireless networks using protocols such as IEEE802.11x 
and Bluetooth have been coming into widespread use, along with the 
provision of data telecommunications using wireless networks. Systems 
for this purpose are equipped with a central server or central point 
and do not have the purpose of carrying out peer-to-peer 
telecommunications . 

In order to perform multi-hop peer-to-peer telecommunications 
on a wireless network, each terminal on the route must correctly 
perform routing control of the packets . However, in the conventional 
routing control technology on the Internet, it is thought to be highly 
probable that the routing information updates cannot stay current on 
networks with severe topology changes . On a wireless network, because 
Node = Device moves within a broad area, the connection point to the 
network changes frequently. It also sometimes seems as if the 
terminal itself has disappeared due to a shutdown or going out of radio 
range . 

An object of the present invention is to provide a protocol making 
possible correct routing control in a network with such severe 
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topology changes and a radio terminal telecommunications method. 

SUMMARY OF THE INVENTION 

5 The present invention is a method for performing multi-hop 

peer-to-peer telecommunications on a wireless network, which includes 
a plurality of radio terminals, and topology of which changes moment 
by moment and, comprising the steps in which: 

each radio terminal exchanges the link state with radio 

10 terminals capable of direct communications (the link state including 
only information on radio terminals within a predetermined number of 
hops), and constructs a routing table; 

a packet is prepared including a routing stack for storing 
intermediate routing information therefor whenever the packet passes 

15 through the terminals; 

a sender terminal designates a destination terminal to 

broadcast the packet; 

the radio terminals on the route, which receive the packet, 
write the intermediate routing information to the routing stack while 
20 transferring the packet to all radio terminals based on the routing 
table; 

the destination terminal which receives said packet returns 
said packet to said sender terminal through the route followed by said 
packet based on information in said routing stack; and 
25 said sender terminal which receives said packet unicasts 

a message to said destination terminal through the radio terminals 
on said route based on information in said routing stack included in 
said packet. 

The present invention is a telecommunications method for radio 
30 terminals, constituting a wireless network, and comprising: 

a routing table generating step, wherein the link state is 
exchanged with radio terminals capable of direct communication (this 
link state includes only information on radio terminals within a 
predetermined number of hops), and a routing table is constructed; 
35 a transferring step for transferring the received packet, when 

this packet is not addressed to itself, to a prescribed terminal based 
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on the intermediate routing information in the routing stack included 
in the packet and the contents of the routing table; 

a source routing demand packet transfer step for writing the 
intermediate routing information to the routing stack included in the 
5 packet when the received packet is a source routing demand packet and 
is broadcast, while transferring the packet to all radio terminals 
based on the routing table; and 

a source routing demand packet return step for transferring the 
packet to the prescribed terminal based on the intermediate routing 
10 information in the routing stack included in the packet, and the 
contents of the routing table, when the received packet is a source 
routing demand packet and undergoes sendback unicast from the terminal 
to the sender terminal. 

A program relating to the present invention causes a processor 
15 to execute the aforementioned method. The program relating to the 
present invention is recorded on a recording medium, for example. 

The medium includes, for example, an EPROM device, flash memory 
device, flexible desk, hard disk, magnetic tape , magneto-optical disk, 
CD (including CD-ROM, video CD), DVD (including DVD-Video, DVD-ROM, 
20 DVD-RAM), ROM cartridge, RAM memory cartridge with battery backup, 
flash memory cartridge, non-volatile RAM cartridge, or the like. 

The medium also includes telecommunications media such as a wired 
telecommunications medium like a telephone circuit, or a wireless 
telecommunications medium like a microwave circuit. The Internet is 
25 also included in such telecommunications media. 

A medium is a device to which information (mainly digital data 
and programs) is recorded by some physical means and can also cause 
a processing device such as a computer or dedicated processor to carry 
out prescribed functions. In short, the medium may be a device which 
30 downloads a program to a computer by some means and causes the execution 
of prescribed functions. 

BRTEF DESCRIPTION OF THE DRAWINGS 

35 Figure 1 shows an example of network topology to explain the 

routing protocol relating to an embodiment of the present invention; 
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Figure 2 shows an example of a routing table relating to an 
embodiment of the present invention; 

Figure 3 shows a flowchart of the link state acquisition 
processing between neighboring terminals in an embodiment of the 
present invention ; 

Figure 4 shows the topology in Figure 1 as seen from terminal 

IB; 

Figure 5 shows the topology in Figure 1 as seen from terminal 

1A; 

Figure 6 shows the state of broadcasting from terminal 1A in 
Figure 1; 

Figure 7 shows the state of the routing stack in the case of Figure 

6; 

Figure 8 shows a flowchart of the sender terminal processing in 
an embodiment of the present invention; 

Figure 9 shows a flowchart of the destination terminal processing 
in an embodiment of the present invention; 

Figure 10 shows a flowchart of the processing of mid-route 
terminals in an embodiment of the present invention; and 

Figure 11 shows a flowchart of the stack reconstruction 
processing in an embodiment of the present invention. 

DESCRIPTION OF THE PREFERRED EMB ODIMENTS 

Following is a detailed explanation of a routing protocol 
relating to the present invention (hereinafter referred to as 
" Jnutella routing protocol" ) using the example of the network topology 
in Figure 1 . In this drawing, the circles 1 containing letters indicate 
each terminal. The solid lines between the plurality of terminals 1 
show sessions between the terminals 1 . A terminal 1 is a mobile terminal 
such as a portable telephone, portable information terminal, or 
notebook personal computer. A terminal 1 can conduct communications 
with other terminals 1 within a prescribed covered area. A terminal 
1 can communicate through the network with a terminal 1 outside of 
the covered area. For example, in Figure 1, even though the terminal 
IF is outside the covered area of the terminal 1A and cannot communicate 
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directly , the terminal 1A can communicate with the terminal IF through 
terminals IB, ID, and IE. Each terminal 1 has the routing table of 
Figure 2 . 

The Jnutella routing protocol employs a proactive model wherein 

5 a link state having the structure in Figure 2 is periodically exchanged 
between neighboring terminals 1, and a routing table is constructed 
in advance regardless of the data communications timing. Figure 3 is 
a flowchart showing this processing in a terminal 1. 

Figure 3 SI: Processing for exchanging link information between 

10 neighboring terminals at a prescribed time will be explained. This 
process comprises Steps S2 through S5 in Figure 3. This process is 
explained specifically with reference to Figures 4 and 5 below. 

Figure 4 shows a situation in which the terminal IB acquires the 
link state from neighboring terminals 1A, 1C , and ID. Here, the 

15 terminals 1A, 1C, and ID are all within the covered area of the terminal 
IB and the terminal IB can communicate directly with each of the 
terminals 1A, 1C , and ID. The terminal IB receives the link state of 
terminal 1A from the terminal 1A itself and the link state of terminal 
1C from the terminal 1C itself , while receiving the information of 

20 the terminal ID, as well as of terminals IE and IF, from the terminal 
ID itself. For this reason, the terminal IB can be informed of the 
existence of IE and IF (the terminal IB cannot communicate directly 
with these terminals) which are beyond the terminal ID. 

Figure 3 S2: The process for extracting the information on 

25 terminals within the predetermined hop area from a terminal's own 
routing table will be explained. 

In this protocol, each terminal 1 does not exchange all the link 
information known by itself at once, but causes the refresh rate to 
vary according to the scope ( number of hops to partner ) of the terminal . 

30 This is because it is highly probable that the link information on 
a terminal at scope more distant than necessary becomes invalid by 
the time of its relay transmission to the other party according to 
the procedures in Figure 3 due to the extreme routing changes in the 
mobile environment. 

35 In this protocol, the refresh rate is caused to change per three 

hops, for example. Figure 5 shows an example of this case. In Figure 
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4, the terminal IB possesses the link state of terminals 1A, 1C, and 
ID through IF. In the case in Figure 5 where the terminal 1A attains 
the link state from the terminal IB, terminals at over three hops as 
seen from the terminal 1A (the receiving side), specifically the 

5 terminal IF (4 hops from terminal 1A to terminal IF) , are deleted from 
the link information transferred by the terminal IB. The terminal IF 
is not registered in the routing table within a three hop range as 
seen from the terminal 1A. In effect, the terminal IF cannot be seen 
from the terminal 1A. This method makes it possible for a terminal 

10 to stabilize and acquire the route information within the number of 
hops important for itself, while suppressing the telecommunications 
band periodically used in order to exchange link information. 

The procedures for carrying out peer-to-peer telecommunications 
according to an embodiment of the present invention will be explained 

15 next with reference to Figures 6 through 11. 

As discussed above, each terminal 1 possesses only the link state 
on terminals within a predetermined number of hops (=3) and does not 
have link information for terminals outside the hop range. As a result, 
the terminals 1A and IF in Figure 1 can only use broadcasting to 

20 exchange packets. This is inefficient compared to the shortness of 
the number of hops. If the number of hops is increased (to the number 
of hops = 4 in Figure 1), this problem can be resolved. However, it 
becomes necessary to increase the refresh rate in order to fill in 
the time difference of the number of hops for transmitting when the 

25 scope of link state exchange is expanded. Also, the telecommunications 
band is consumed unnecessarily. For this reason, in the embodiment 
of the present invention, the scope of link state exchange is kept 
narrow, but also doubles as an on-demand type source routing which 
uses the packet construction. Figure 7 shows an example of the route 

30 stack table for realizing this routing and Figures 8 through 11 show 
flowcharts of the processing in each terminal. 

In the following explanation, "broadcast" indicates the 
multi-hop transfer of a received message to all connected nodes. 
"Unicast" indicates the multi-hop transfer of a received message to 

35 specific connected nodes. "Sendback unicast" indicates the return of 
a received message to the sender along the route it traveled. 
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If the scope of link state exchange is S and the depth of the 
route stack: is D, S + D is the communications radius of the theoretical 
unicast in the embodiment of the invention (for example, S = 3 or 5, 
D = 7) . 

5 In the protocol relating to this embodiment of the invention, 

the intermediate route information whenever the packet passes through 
a terminal is stored within the packet (See S3 5 through S3 8 in Figure 
10). This is called the route stack. Also, the package has a stack 
pointer for showing the location of the value which should be acquired 

10 next from the route stack. The data sender terminal broadcasts the 
packet (See S10, Sll Figure 8) , whereby the return route to the sender 
is embedded in the route stack of that packet at the time it arrives 
at the destination terminal. 

Moreover, in the case where it is known in advance that the 

15 destination terminal is present in the routing table (Figure 8, SlOa, 
YES), the packet is unicast to the destination terminal based on the 
routing table, instead of being broadcast in Sll (SlOb). 

Specifically, upon broadcasting from the terminal 1A in Figure 
6, the interior of the routing stack becomes as shown in Figure 7 at 

20 the time when the packet arrives at the terminal IF. Values layered 
in the stack are the terminal's local link ID or Identity. The link 
ID or Identity may be uniform between neighboring terminals, but does 
not need to be globally uniform. Also, the zero is reserved in advance 
for the link ID or Identity indicating that the stack is empty. 

25 In this embodiment of the present invention, an addressing system 

such as IP is not employed. There is instead the concept of "Identity" 
(link ID) . The important function of Identity is "the abstraction of 
node identity" . In the protocol of this embodiment of the present 
invention, if the Identity .equalsO method (terminal identification 

30 method) returns FALSE, that node is determined to be another 

individual. Message transmission and reception in this embodiment of 
the present invention is sent to all of these Identities. 

When the terminal IF returns a packet (sendback unicast), the 
terminals (for example, terminal IE) on the route move the stack 

35 pointer, and at the same time retrieve the link ID or Identity, and 
transfer the packet to the neighboring terminal corresponding to that 
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value (See S39, S40, S42 in Figure 10). It becomes possible to return 
data to the sender when each terminal 1 on the route carries out this 
process . The transfer speed is high since this process does not require 
searching of the routing table. 
5 Terminal 1A can send packets to the destination terminal based 

on the routing stack of the returned packet (S12 , S13 in Figure 8). 

Consider a case wherein the link between the terminal ID and the 
terminal IE is cut and instead a new link is formed between the terminal 
1C and the terminal IE. At the time when a packet is returned from 
10 the terminal IF to the terminal IE, it becomes necessary to reconstruct 
the stack because the transfer point corresponding to the link ID of 
the next hop or Identity is lost (YES in S42 Figure 10). 

Figure 11 shows an example of the stack reconstruction process. 
When it is determined that the value is invalid, the stack is completely 
15 cleared ( S50 ) , and broadcasting is again constructed from the terminal 
IE toward the terminal 1A (S51, S52). The terminal 1A receives this 
packet and sends the packet to the destination terminal IF. 

The protocol in this embodiment of the present invention operates 
in a network environment wherein the topology can change easily, such 
20 as a wireless network, and designates an application level P2P 
Protocol. This has the following characteristics. 
( 1 ) Ad hoc network 

In a wireless network, the connection point to the network is 
frequently switched because Node = Device moves over a broad area. 
25 It may also seem as if the terminal itself disappears due to shutdowns 
and going out of radio range. It can therefore be said that: 

a static node table covering the entire network area does not 
exist; 

the network position of a node cannot be estimated from the 
30 individual information of the terminal such as the device ID; and 
it is possible that a route that was valid at one moment may be 
entirely lost the next. 

The protocol of this embodiment of the present invention can operate 
without failure under these conditions. 
35 (2) Fully decentralized 

A central server or central point used in other protocols/systems 
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is not a key part of the architecture. On a wireless network such as 
the Internet where Reachability cannot be presupposed, it may not be 
possible to discover a central point ("server" in conventional 
terminology) even if the server is present. A central point is a 
5 peripheral element introduced "arbitrarily", such by a company 
ensuring traffic quality for users. 
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